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Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


The Point-to-Point Protocol (PPP) [1] provides a standard method of 
encapsulating Network Layer protocol information over point-to-point 
links. PPP also defines an extensible Link Control Protocol, and 
proposes a family of Network Control Protocols (NCPs) for 
establishing and configuring different network-layer protocols. 


This document defines the NCP for establishing and configuring 
Digital’s DNA Phase IV Routing protocol (DECnet Phase IV) over PPP. 
This document applies only to DNA Phase IV Routing messages (both 
data and control), and not to other DNA Phase IV protocols (MOP, LAT, 
etc). 


1. Introduction 


There are two basic approaches to running the DNA Phase IV Routing 
protocol over a serial line: 


1. The approach that several router vendors have taken which is to 
treat the serial link as an Ethernet, using the same data and 


control messages an Ethernet would use. 


2. The approach defined by Digital, which uses DDCMP and slightly 
different control messages. 


This document will define a method that uses the first approach. 
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2. Overview Of Phase IV DNA Protocols 
The Phase IV DNA protocols which act as data link clients are: 


o DNA Phase IV Routing 
The Phase IV Digital Network Architecture (DNA) Routing 
protocol is a network layer protocol providing services similar 
to that of DoD IP. It routes messages in Phase IV DECnet 
networks and manages the packet flow. The complete definition 
of the DNA Phase IV Routing protocol can be found in [2]. 


o DNA System Console 
The Digital Network Architecture (DNA) System Console protocol 
is a maintenance protocol providing low level access to a 
system for the functions of: 


Identify processor 

Read data link counters 

Boot system 

Console carrier (a general purpose i/o channel) 


The complete definition of the DNA System Console protocol can 
be found in [3]. 


o Digital Customer Use 
The Digital Customer Use protocol is a value reserved for use 
by Digital customers. It allocates a type for private use 
which will not conflict with Digital or other vendor protocols. 


o DNA Diagnostics 
The Digital Network Architecture (DNA) Diagnostics protocol is 
reserved to allow diagnostic software communications in 
parallel with other data link clients. 


o DNA Naming Service (DNS) 
The Digital Network Architecture Naming Service (DNS) provides 
a distributed naming service. It allows clients to register 
named objects and to bind a set of attributes to the objects in 
a distributed database. 


o DNA Time Service (DTS) 
The Digital Network Architecture Time Service (DTS) is a 
protocol providing global clock synchronization ina 
distributed environment. 


Senum [Page 2] 


RFC 1762 PPP DNCP March 1995 


o DNA Load/Dump 
The Digital Network Architecture (DNA) Load/Dump protocol is a 
maintenance protocol for copying the contents of processor 
memory to or from a remote system. For example, a system 
manager can load an operating system into an unattended, remote 
system. The complete definition of the Phase IV DNA Load/Dump 
protocol can be found in [3]. 


o DNA Experimental Use 
The Digital Network Architecture (DNA) Experimental Use 
protocol allows Digital experimental protocols to share a data 
link with other data link clients. It is for use by Digital 
Equipment Corporation only. 


o DNA Communications Test 
The Digital Network Architecture (DNA) Communications Test 
protocol is a maintenance protocol for testing the data link 
communications path. The complete definition of the DNA 
Communications Test protocol can be found in [3]. 


o Digital Protocol X1 
The Digital X1 protocol is a network layer protocol currently 
private to Digital. 


This document defines the NCP for establishing and configuring 
Digital’s DNA Phase IV Routing protocol (DECnet Phase IV) over PPP. 
This document applies only to DNA Phase IV Routing messages (both 
data and control), and not to other DNA Phase IV protocols. 


3. A PPP Network Control Protocol for DNA Phase IV Routing 


The DNA Phase IV Routing Control Protocol (DNCP) is responsible for 
configuring, enabling, and disabling the DNA Phase IV Routing 
protocol modules on both ends of the point-to-point link. DNCP uses 
the same packet exchange mechanism as the Link Control Protocol 
(LCP). DNCP packets may not be exchanged until PPP has reached the 
Network-Layer Protocol phase. DNCP packets received before this 
phase is reached should be silently discarded. 


The DNA Phase IV Routing Control Protocol is exactly the same as the 
Link Control Protocol [1] with the following exceptions: 


Frame Modifications 


The packet may utilize any modifications to the basic frame format 
which have been negotiated during the Link Establishment phase. 
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Data Link Layer Protocol Field 


Exactly one DNCP packet is encapsulated in the Information field 
of a PPP Data Link Layer frame where the Protocol field indicates 
type hex 8027 (DNA Phase IV Control Protocol). 


Code field 


Only Codes 1 through 7 (Configure-Request, Configure-Ack, 
Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack 
and Code-Reject) are used. Other Codes should be treated as 
unrecognized and should result in Code-Rejects. 


Timeouts 


DNCP packets may not be exchanged until PPP has reached the 
Network-Layer Protocol phase. An implementation should be 
prepared to wait for Authentication and Link Quality Determination 
to finish before timing out waiting for a Configure-Ack or other 
response. It is suggested that an implementation give up only 
after user intervention or a configurable amount of time. 


Configuration Option Types 


DNCP has no Configuration Options. 


4. Sending DNA Phase IV Routing Packets 


Senum 


Before any DNA Phase IV Routing packets may be communicated, PPP 
must reach the Network-Layer Protocol phase, and the DNA Phase IV 
Routing Control Protocol must reach the Opened state. 


Exactly one length field and one DNA Phase IV Routing packet are 
encapsulated in the information field of a PPP Data Link Layer 
frame where the Protocol field indicates type hex 0027 (DNA Phase 
IV Routing). The length field contains a count of the number of 
octets in the DNA Phase IV Routing packet. It is two octets in 
length itself, and is stored in VAX byte ordering, to be more 
consistent with DNA Phase IV Routing over Ethernet (i.e. least 
significant byte first). It is needed to disambiguate optional 
padding octets from real information. 


The maximum length of a DNA Phase IV Routing packet transmitted 
over a PPP link is the same as the maximum length of the 
Information field of a PPP data link layer frame minus 2 octets 
(for the Length field). 
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The format of the packets themselves is the same as the format 
used over Ethernet, without the Ethernet header, Pad, and FCS 
fields. 


A summary of the information field is shown below. The fields are 
transmitted from left to right. 


0 l 2 3 

Op T2 345 Oe Hh BO OTs 2: 3 456 68: 9-08 T S A 6-78 9 OL 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Length LSB | Length MSB | DATA | a | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| | 


Sf SAE ec aah eRe a Pa ge copa LG et ee ir 
Length LSB 
Least significant byte of length field 
Length MSG 
Most significant byte of length field 
DATA 
DNA Phase IV Routing data, as specified in [2] 
5. General Considerations 


When a topology change in the network occurs, DNA Phase IV Routing 
nodes immediately propagate changes via Level 1 and Level 2 Routing 
messages, with a 1 second minimum delay between updates. DNA Phase 
IV Routing nodes also periodically retransmit the complete Level 1 
and Level 2 distance vectors to guard against data corruption in host 
memory, and (in the case of Ethernet) loss of packets due to media 
errors. Because Digital’s serial links run a protocol that 
guarantees delivery of packets (DDCMP), the recommended default 
retransmit time is long (600 seconds), whereas for Ethernet, where 
packet delivery is not guaranteed, the recommended default is short 
(10 seconds), as documented in [2]. To achieve convergence of routes 
within a satisfactory time, the interval between updates should be 
based upon the error rate of underlying data link. As such, it is 
recommended that the time between routing updates be user 
configurable per PPP interface. 


The Hello timer and Listen timer should be set according to the 
recommendations for broadcast links (15 and 45 seconds, 
respectively). 
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Routers MAY not send routing updates if the remote node connected via 
the PPP link is an endnode. Endnodes MUST discard all routing 
updates received over a PPP link. The type of a node (endnode versus 
routing) can be determined from the hello messages received from it. 


Security Considerations 
Security issues are not discussed in this memo. 
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